home *** CD-ROM | disk | FTP | other *** search
- From: "Eugene Lazutkin" <INT@msn.com>
- Message-ID: <UPMAIL04.199602192354280583@msn.com>
- X-Original-Date: Mon, 19 Feb 96 23:49:01 UT
- Path: in2.uu.net!bounce-back
- Date: 20 Feb 96 07:15:52 GMT
- Approved: fjh@cs.mu.oz.au
- Organization: -
- Newsgroups: comp.std.c++
- Subject: RE: Portability. Modules. WAS: RE: Are all Windows programs
- ill-formed?
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBFAgUBMSl1geEDnX0m9pzZAQFVcAF5AR1Q85NvC1wBpg9XO5ni6I5JAkvj1I6J
- vIOAOG1Z6DUPBAJLGRBAUKXFKIj/oG0f
- =XM7Z
-
- On Tuesday, February 13, 1996 7:48 AM,
- James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:
- > In article <01BAF61B.3131B100@dino.int.com> Eugene Lazutkin
- > <eugene@int.com> writes:
- >
- > |> On Tuesday, February 06, 1996 9:18 PM,
- > |> rich@kastle.com (Richard Krehbiel) wrote:
- >
- > [...]
- > |> Another point of non-portability is #pragmas. Static containers are
- > |> almost useless unless you can specify the order of their
- > |> construction/destruction.
- >
- > This depends on the design of the container. See below for two ways
- > of handling this.
- >
- > |> Borland provides you with #pragma
- > |> startup/exit (am I correct with names?). With this tool you can specify
- > |> a priority. It is not a ultimate medicine but it helps a lot!
- >
- > It helps make your programs non-portable, you mean:-) (as you point
- > out). There are better solutions.
-
- I don't like this solution either. But it works. See below.
-
- > The oldest one, rarely used except for the simplest cases today, is to
- > design the list such that the initial initialization to 0 is adequate,
- > and give it a special no-op constructor. Thus, for example, my
- > command line parser class maintains a list of options (staticly
- > declared objects); a NULL pointer signifies an empty list, and the
- > constructor does nothing. Thus, it doesn't matter if the options are
- > constructed (and register themselves) before the list.
-
- It doesn't help to create a simple double-linked ring. Not all
- containers can be built on a single-linked list or a tree structure.
- E.g., any member of a double linked ring can exclude itself from the
- list automatically by its destructor at any time. You can't do it
- with single-linked list or with double-linked list (not ring).
-
- BTW, who frees the allocated memory? When? How can I specify the
- order of destruction? ObjectSpace's STL has problems with that.
- The program using this STL will leak. They can't eleminate this
- problem. OK, they have a work around. But it is very inefficient:
- they use per-object allocators instead of per-class.
-
- > The more frequent solution today is to have a function returning a
- > reference to a local static object. The object will be constructed
- > the first time the function is called. The enrolment functions in the
- > Item's call the function to get the actual list object.
-
- Does this static object have any constructors? Or its components?
- Is it based on some class without constructors? If not, who will
- be initialize it? And how? Who will deinitialize it? A lot of
- problems.
-
- Of course, both these solutions work just fine in certain specific
- cases. But it is not a generic answer. It is a trick.
-
- > I often encapsulate the above solution in a SharedList interface
- > class. All instances of the SharedList actually refer to the same
- > list object. The SharedList only contains a pointer to the actual
- > list object, and forwards all requests to it. The pointer is
- > initialized by calling the function above in the constructor.
- >
- > |> Alternative way: include all items into the container manually and
- > |> don't forget to do this initialization every time when you use this
- > |> container in your program.
- >
- > This is extremely error prone (as you also point out). If you are
- > willing to accept that all of the objects are known in the same
- > compilation unit, you might as well define them there, and let the
- > guaranteed order of construction within the compilation unit do the
- > trick.
-
- This is C++, not Pascal. We have separate units. I think it is too
- strong requirement to put some logically different items together.
- I think it is too error-prone.
-
- Eugene Lazutkin
- eugene@int.com
- ---
- [ To submit articles: try just posting with your news-reader.
- If that fails, use mailto:std-c++@ncar.ucar.edu
- FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
- Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
- Comments? mailto:std-c++-request@ncar.ucar.edu.
- ]
-